Revision: tla--devo--1.3.1--patch-10
Archive: lord@emf.net--2005
Creator: Thomas Lord <lord@emf.net>
Date: Mon Feb 14 02:49:31 PST 2005
Standard-date: 2005-02-14 10:49:31 GMT
Modified-files: libarch/ancestry.c
    libarch/apply-changeset.c libarch/archive-setup.c
    libarch/archive.c libarch/archives.c
    libarch/changelogs.c libarch/changeset-report.c
    libarch/changeset-utils.c libarch/cmd-abrowse.c
    libarch/cmd-archive-setup.c libarch/cmd-changes.c
    libarch/cmd-changeset.c libarch/cmd-commit.c
    libarch/cmd-library-revisions.c libarch/cmd-rbrowse.c
    libarch/cmd-replay.c libarch/cmd-revisions.c
    libarch/commit.c libarch/configs.c libarch/diffs.c
    libarch/inode-sig.c libarch/inv-ids.c libarch/invent.c
    libarch/libraries.c libarch/library-txn.c
    libarch/make-changeset-files.c libarch/make-changeset.c
    libarch/merge-points.c libarch/missing.c libarch/my.c
    libarch/patch-logs.c libarch/pfs-ftp.c
    libarch/pfs-sftp.c libarch/pfs-signatures.c
    libarch/pristines.c libarch/proj-tree-lint.c
    libarch/star-merge.c libarch/tag.c libarch/whats-new.c
    libawk/associative.c libawk/associative.h
    libawk/relassoc.c libawk/relational.c
    libawk/relational.h libfsutils/dir-listing.c
    libfsutils/find-utils.c
New-patches: lord@emf.net--2005/tla--devo--1.3.1--patch-10
    lord@emf.net--libawk-exp-2005/tla--reltable-construction--1.3.1--base-0
    lord@emf.net--libawk-exp-2005/tla--reltable-construction--1.3.1--patch-1
    lord@emf.net--libawk-exp-2005/tla--reltable-construction--1.3.1--patch-2
    lord@emf.net--libawk-exp-2005/tla--reltable-construction--1.3.1--patch-3
    lord@emf.net--libawk-exp-2005/tla--reltable-construction--1.3.1--patch-4
    lord@emf.net--libawk-exp-2005/tla--reltable-construction--1.3.1--patch-5
    lord@emf.net--libawk-exp-2005/tla--reltable-construction--1.3.1--patch-6
    lord@emf.net--libawk-exp-2005/tla--reltable-construction--1.3.1--patch-7
    lord@emf.net--libawk-exp-2005/tla--reltable-construction--1.3.1--patch-8
    lord@emf.net--libawk-exp-2005/tla--reltable-construction--1.3.1--patch-9
    lord@emf.net--libawk-exp-2005/tla--reltable-construction--1.3.1--patch-10
    lord@emf.net--libawk-exp-2005/tla--reltable-construction--1.3.1--patch-11
    lord@emf.net--libawk-exp-2005/tla--reltable-construction--1.3.1--patch-12
    lord@emf.net--libawk-exp-2005/tla--reltable-construction--1.3.1--patch-13
    lord@emf.net--libawk-exp-2005/tla--reltable-construction--1.3.1--patch-14
    lord@emf.net--libawk-exp-2005/tla--reltable-construction--1.3.1--patch-15
    lord@emf.net--libawk-exp-2005/tla--reltable-construction--1.3.1--version-0
Summary: [on bug libawk-api-bogosities] step 4 of libawk cleanup
Keywords: 


  [[cartouche
     You will also need to build with a version of `libhackerlab'
     that includes the changes found in:

     /Archive:/ `lord@emf.net--2005'

     /Version:/ `hackerlab--devo--1.1'

     /Revisions:/ `patch-4'
  ]]

  `libarch' contains 150-something calls to one of the small number of
  `libawk' functions that accept a `const t_uchar *' 0-terminated 
  string and create a relational table entry or associative key or 
  value from that string.

  That's unfortunate.  Many of those strings are copied from other
  table entries but a `t_uchar *' based interface loses that
  information and so deprives `libawk' of an opportunity to share
  a single string between multiple relational and associative table
  slots.

  This step half fixes that problem.  Specifically, the table
  interfaces are modified so that strings which might wind up being
  saved by `libawk' must be passed as `rel_field' values, which are
  reference counted, passing a value with an "extra" reference which
  `libawk' will consume.

  A typical code change replaces the idiom:

  [[tty
        rel_set_str (table, x, y, "hello world");
  ]]

  with

  [[tty
        rel_set_field (table, x, y, rel_make_field_str ("hello world"));
  ]]


  No (well, very little, actually) new string sharing is caused by
  this change alone.  In particular, many examples persist along
  the lines of:

  [[tty

        const t_uchar * s;

        s = rel_peek_str (table_a, x, y);

        rel_set_field (table_b, i, j, rel_make_field_str (s));

   ]]

   In that example, although the same string could have been shared
   between tables `a' and `b', `libawk' can't cheaply know that
   because the client has freshly allocated a new copy of the
   string by calling `rel_make_field_str'.

   The next step will take care of those.

